|
|
|
|
|
|
|
Figure 5.2.
Some UML icons. |
|
|
|
|
|
|
|
|
The Package icon (upper-left corner) represents a group of related classes and subpackages. The unidirectional association between the Actor and the UseCase (top) represents an association in which the Actor is providing stimulus to the UseCase, but no stimulus flows back to the Actor from the UseCase. The association between Class4 and Class3 is not as strict and can be interpreted as bidirectional (either class at the end of the association can provide stimulus to the other). The dependency relationship between Class1 and Class2 is the weakest coupling between two objects and specifies that not much is known about the relationship, other than that Class1 somehow depends on Class2. It's similar to a unidirectional association, except the latter implies this information about the class on the receiving end. Finally, the relationship between Class1 and SubClass is one of inheritance. This is the same icon you use for interface inheritance, with a stereotype of <implements>>. A stereotype is an abstract characterization of a class. |
|
|
|
|
|
|
|
|
The Importance of Not Deviating from the Architecture |
|
|
|
|
|
|
|
|
An application's architecture is its skeletal system. Just as humans have a well-defined skeletal architecture, so do well-designed applications have well-defined architectures. This emphasis on application architecture is not only important in corporate development environments but also for personal projects. Having an architecture in place before the programming phase is like making rough drafts of a document before developing the final draft. When you're developing applications in the comfort of your home or office, |
|
|
|
|
|
